Recovery key for unlocking a data storage device

ABSTRACT

Disclosed herein is a data storage device comprising a data path and an access controller. The access controller generates a recovery private key, generates encrypted authorization data based on the recovery private key, stores the encrypted authorization data, and sends the recovery private key to a manager device. When recovery is desired, access controller receives a recovery public key, calculated based on the recovery private key, from a recovery manager device, decrypts the encrypted authorization data based on the recovery public key, generates a challenge for the recovery manager device based on the decrypted authorization data, sends the challenge to the recovery manager device over the communication channel that is different from the data path, receives a response to the challenge from the recovery manager device over the communication channel, and based at least partly on the response, enables decryption of the encrypted user content data.

TECHNICAL FIELD

This disclosure relates to a data storage device that can be unlockedusing a recovery key.

BACKGROUND

Encryption of data enables relatively secure storage on data storagedevices, such as block data storage devices connectable via a UniversalSerial Bus (USB) cable. However, the user experience is oftendisappointing because the setup of passwords, keys and the like iscumbersome and complicated for technically unskilled users. Ifencryption is used, the keys and passwords are too often storedinsecurely. As a result, many users leave existing encryption technologyeffectively unused resulting in exposed confidential data.

SUMMARY

This disclosure provides a data storage device that can be unlocked witha recovery key. While the data storage device provides the recovery keyto a registered manager device, it is not necessary for a differentrecovery manager device, that is not yet registered, to provide therecovery key itself to the data storage device. Nevertheless, therecovery manager device can become registered with full access even ifthe recovery key is the only information available to the recoverymanager device. The data storage device does not employ a system basedon access control list, such as common operating system. Instead, accessto data objects, such as keys, user content data or configuration data,is governed by cryptographic methods in the sense that data objects canbe decrypted if the suitable key is available regardless of whether auser or connected device has a particular role.

Disclosed herein is a data storage device comprising a data path and anaccess controller. The data path comprises a data port configured totransmit data between a host computer system and the data storagedevice; a non-volatile storage medium configured to store encrypted usercontent data; and a cryptography engine connected between the data portand the storage medium and configured to use a cryptographic key todecrypt the encrypted user content data stored on the storage medium inresponse to a request from the host computer system. The accesscontroller is configured to: generate a recovery private key; generateencrypted authorization data based on the recovery private key; storethe encrypted authorization data in a data store; send data indicativeof the recovery private key to a manager device; receive a recoverypublic key, calculated based on the recovery private key, from arecovery manager device over a communication channel that is differentfrom the data path; decrypt the encrypted authorization data based onthe recovery public key; generate a challenge for the recovery managerdevice based on the decrypted authorization data; send the challenge tothe recovery manager device over the communication channel that isdifferent from the data path; receive a response to the challenge fromthe recovery manager device over the communication channel; and based atleast partly on the response, enable decryption of the encrypted usercontent data.

In some embodiments, the recovery private key is stored on the recoverymanager device and the response is based on the recovery private keystored on the recovery manager device.

In some embodiments, the manager key enables configuration of the accesscontroller to enable decryption of the encrypted user content data.

In some embodiments, the manager key enables registration of anauthorized device with the access controller to enable decryption of theencrypted user content data in response to the authorized device beingconnected to the data storage device.

In some embodiments, registration of the authorized device comprisescreation of an entry as further encrypted authorization data in the adata store based on a public key associated with the authorized device;the entry comprises an encrypted user key calculated based on themanager key; and the access controller is configured to determine thecryptographic key based on the user key.

In some embodiments, the encrypted authorization data based on therecovery private key has a first structure that is identical to a secondstructure of encrypted authorization data based on the public keyassociated with the authorized device that is authorized to unlock thedata storage device by responding to a challenge generated by the accesscontroller.

In some embodiments, the first structure and the second structurecomprise a respective public key field, the access controller isconfigured to store the recovery public key in the public key field ofthe first structure and to store the public key associated with theauthorized device in the public key field of the second structure.

In some embodiments, the user key is directly derivable from the managerkey.

In some embodiments, the access controller is further configured todetermine, based at least partly on the response, a manager key toenable decryption of the encrypted user content data.

In some embodiments, the access controller is further configured todetermine the cryptographic key based on the manager key.

In some embodiments, the encrypted authorization data comprises metadataencrypted by a pre-authorization metadata wrapping key that is derivablefrom the recovery public key.

In some embodiments, the access controller is configured to derive thepre-authorization metadata wrapping key by performing a key derivationfunction using the recovery public key as an input.

In some embodiments, the access controller is further configured toperform the key derivation function using an authorized device slot keyas a further input.

In some embodiments, the authorized device slot key is stored on thedata store in plain text.

In some embodiments, the access controller is configured to generate thechallenge for the recovery manager device based on the metadata; and theencrypted authorization data comprises a manager key that is encryptedby an unlock secret that is derivable from the response to enabledecryption of the encrypted user content data.

In some embodiments, the metadata comprises an elliptic curve public keycorresponding to an ephemeral unlock key; and the unlock secret is basedon the ephemeral unlock key.

In some embodiments, the access controller is configured to deleteauthorization data other than the generated encrypted authorization databased on the recovery private key in response to enabling decryption.

In some embodiments, the recovery public is calculated by the accesscontroller and the recovery manager device.

Disclosed herein is a method for unlocking a data storage device thatstores encrypted user content data. The method comprises generating arecovery private key; generating encrypted authorization data based onthe recovery private key; storing the encrypted authorization data in adata store; sending data indicative of the recovery private key to amanager device; receiving a recovery public key, calculated based on therecovery private key, from a recovery manager device over acommunication channel; decrypting the encrypted authorization data basedon the recovery public key; generating a challenge for the recoverymanager device based on the decrypted authorization data; sending thechallenge to the recovery manager device over the communication channel;receiving a response to the challenge from the recovery manager deviceover the communication channel; and enabling, based at least partly onthe response, decryption of the encrypted user content data.

Disclosed herein is a data storage device comprising means forgenerating a recovery private key; means for generating encryptedauthorization data based on the recovery private key; means for storingthe encrypted authorization data in a data store; means for sending dataindicative of the recovery private key to a manager device; means forreceiving a recovery public key, calculated based on the recoveryprivate key, from a recovery manager device over a communicationchannel; means for decrypting the encrypted authorization data based onthe recovery public key; means for generating a challenge for therecovery manager device based on the decrypted authorization data; meansfor sending the challenge to the recovery manager device over thecommunication channel; means for receiving a response to the challengefrom the recovery manager device over the communication channel; andmeans for enabling, based at least partly on the response, decryption ofthe encrypted user content data.

BRIEF DESCRIPTION OF DRAWINGS

A non-limiting example will now be described with reference to thefollowing drawings:

FIG. 1 illustrates a data storage device, according to an embodiment.

FIG. 2 illustrates a section of the configuration memory of the datastorage device of FIG. 1, according to an embodiment.

FIG. 3 illustrates a control flow between the authorized device and theaccess controller of FIG. 1, according to an embodiment.

FIG. 4 illustrates a certificate issued by the data storage device andsent by the authorized device to the data storage device to unlock thedata storage device, according to an embodiment.

FIG. 5 illustrates a method for unlocking a data storage device using arecovery key, according to an embodiment.

DESCRIPTION OF EMBODIMENTS

FIG. 1 illustrates a data storage device (DSD) 100 comprising a datapath 101 and an access controller 102, according to an embodiment. Thedata path 101 comprises a wire-based data port 103, which is provided inFIG. 1 by a USB bridge, for transmission of data between a host computersystem 104 and the DSD 100. In other embodiments, the data path 101comprises a wireless data port (not shown) for wireless transmission ofdata between the host computer system 104 and the DSD 100. The DSD 100registers with the host computer system 104 as a mass data storagedevice providing the functionality to the operating system of the hostcomputer system 104 of a block data storage device. DSD 100 furthercomprises a non-transitory storage medium 105 to store encrypted usercontent data, noting that the user content data is the data that a userwould typically want to store on a DSD, such as files including imagefiles, documents, video files, etc. The storage medium may be a solidstate drive (SSD), hard disk drive (HDD) with a rotating magnetic diskor other non-volatile storage media. Further, the storage medium may bea block data storage device, which means that the user content data iswritten in blocks to the storage medium 105 and read in blocks from thestorage medium 105.

Command Set

In one example, storage medium 105 comprises a cryptography engine 106in the form of a dedicated and/or programmable integrated circuit thatencrypts data to be stored on storage medium 105 and decrypts data to beread from storage medium 105. In such examples, the storage medium mayprovide a Small Computer System Interface (SCSI) or Advanced TechnologyAttachment (ATA) command set according to the Opal specification by theTrusted Computing Group (TCG).

Program code stored on the cryptography engine 106 enables thecryptography engine 106 to receive, interpret and execute commandsreceived from host computer system 104. For example, cryptography engine106 may be configured to implement the standard ATA or serial ATA (SATA)and/or ATA Packet Interface (ATAPI) command set, which is available fromTechnical Committee T13 noting that identical functionalities can beimplemented within TCG Opal, SCSI and other proprietary architectures.The command set comprises a READ SECTORS command with a command input ofthe count of sectors and the starting sector (noting that “sector” isused synonymously with “block” herein). Accordingly, there is acorresponding write command. It is noted that there is a data storagedevice driver installed on host computer system 104. The data storagedevice driver (not shown) uses the command set to provide high-levelservices to the operating system, such as file read functionalities. Insome examples, the data storage device driver is a generic driversupplied as part of the operating system without support fordevice-specific encryption commands since the encryption functionalityis hidden from the host computer system 104 and handled internallywithin DSD 100 as described below. This means that no additional driversneed to be installed to use the full functionality disclosed herein.

The command set provided by the cryptography engine 106 to the data port103 (but not forwarded to host computer system 104) may include acommand set from the ATA SECURITY feature set. In particular, thecommand set may include the command SECURITY SET PASSWORD or acorresponding command from TCG Opal to set a password for reading andwriting user content data to the storage medium 105.

In this sense, cryptography engine 106 is connected between the dataport 103 and the storage medium 105 and is configured to use acryptographic key to encrypt user content data to be stored on thestorage medium 105 and to decrypt the encrypted user content data storedon the storage medium 105 in response to a request from the hostcomputer system 104. In some examples, the ATA SECURITY feature set isused only by data port 103 and not by host 104. That is, the accesscontroller 102 provides the necessary input for the data port 103 toissue the ATA SECURITY commands to the cryptography engine 106. Forexample, the access controller 102 may provide a key to the data port103, which the data port 103 then forwards to the cryptography engine106 via the SECURITY SET PASSWORD command. The interface between theaccess controller 102 and the data port 103 may be an Inter-IntegratedCircuit (I2C) bus, which is particularly useful in cases where this busis already implemented in existing chips. However, it is possible to usemany other communication architectures including bus, point-to-point,serial, parallel, memory based and other architectures.

Note that the separation of functionalities in dedicated chips as shownin FIG. 1 is only one possible example implementation. Therefore, it ispossible to combine functionalities or split the functionalitiesfurther. For example, data port 103 may be integrated with accesscontroller 102 into a single chip with a single core. In other cases,the data port 103 and the access controller 102 can be integrated withcryptography engine 106 into a single dedicated chip with a single core.Of course, all chips may have multiple cores.

In one example, the following components are used:

-   Data port 103: USB 3.1 Gen 2 10 gigabits per second (Gb/s) interface-   Access controller 102: nRF52840 system-on-chip (SoC) from Nordic    Semiconductor

It is noted that for the functionality disclosed herein, the accesscontroller 102 plays the leading role and will be described in moredetail below, noting again that the tasks may be separated into separatechips in other examples. When reference is made to a ‘configuration’ ofthe access controller 102 or the access controller 102 being‘configured’ to perform a certain step, this is to be understood torelate to program code that is stored on non-volatile memory in the DSD100 on program memory (not shown for clarity) and executed by the accesscontroller 102.

In other examples, some or all steps disclosed herein may be performedby hardware circuitry without program code. In particular, encryptionprimitives may be implemented by dedicated hardware circuitry forperformance and security reasons. For example, commands that areparticularly computationally demanding, such as elliptic curvemultiplication or exponentiation, may be implemented by an ArithmeticLogic Unit (ALU) specifically designed for this calculation, such thatthe calculation can be performed in a single or a smaller number ofprocessor cycles compared to using a sequential program in a generalpurpose microcontroller. It is further noted that the chips included inDSD 100 are microcontrollers, which means in this context that they donot run under an operating system that provides a hardware abstractionlayer but the program code acts directly on the hardware circuit. Whileelliptic curve cryptography is used herein as examples for reasons ofcomputational efficiency and security, it is noted that other public-keycryptosystems, such as the Rivest-Shamir-Adelman (RSA) cryptosystem,could equally be used.

Returning back to FIG. 1, there are a number of devices in addition tohost computer system 104 that are external to the DSD 100 and that actin the process of unlocking the DSD 100 and providing a key to thecryptography engine 106 so that, ultimately, decrypted data in plaintext can be provided to host computer system 104.

In particular, there is a first manager device 110, which is a mobilephone in most examples. Installed on the manager device 110 is anapplication (‘app’) to perform the following steps. In this way, thefollowing steps can be implemented in software by the manufacturer ofthe DSD 100 and distributed to the manager device 110 through a commonlyaccessible app store, such as Apple's App Store or Google Play. The appinstalled on manager device 110 performs steps to take ownership of theDSD 100 at which point all data on the DSD 100 is erased or otherwisemade inaccessible. For example, data may be crypto-erased by securelydeleting all cryptographic keys stored on DSD 100.

For simplicity of presentation, this disclosure describes steps assimply being performed by manager device 110 if they are implemented bythe app. The manager device 110 sets up the DSD 100, which means thevarious different keys are generated to support the process disclosedherein. Manager device 110 registers a user device 111 with the DSD, sothat the user device 111 is then referred to as the “authorized device”111. In most examples, the authorized device 111 is also a mobile phonewith an app installed that implements the steps described as beingperformed by the authorized device 111. However, other types of devicescan be used as authorized devices, which will be explained below inrelation to beacons and key fobs.

Taking Ownership

The first step in using DSD 100 after purchase, unpacking and power-upis to install the app on manager device 110 and register a device as themanager device 110. For this process, the manager device 110 obtains aunique identifier of the DSD from the DSD. This unique identifier isreferred to as the identity key (IDK). In the example illustrated inFIG. 1, the identity key is encoded in a quick response (QR) code 112which is affixed to an external surface of the DSD 100. The appinstalled on manager device 110 has access to a camera and has asoftware module that extracts the encoded information from an image ofthe QR code 112. The manager device 110 captures an image of the QR code112 using the camera, and decodes the identity key of DSD 100 from theQR code. In one example, the QR code encodes a Uniform Resource Locator(URL). In that case, a generic app can capture the QR code, which thenautomatically directs the phone to an application store where the appcan be downloaded. The URL also includes the identity key so that theapp can decode that identifier once the app is installed.

In another example, manager device 110 may read another tag or NFC chipaffixed or integrated with DSD 100 to obtain the identity key. Usingthat identity key, the manager device 110 can then initiate acommunication, such as wirelessly (e.g., over Bluetooth), with the DSD100 and in particular, with the access controller 102.

Registration of Authorized Device

Once the DSD 100 is initially configured during the take ownershipprocess, manager device 110 registers the authorized device 111. .Typically, there may be multiple authorized devices registered with asingle DSD 100 so manager device 110 registers the authorized device asone of multiple authorized devices. More particularly, access controller102 receives from the manager device 110 a public key associated with aprivate key stored on user device 111. The manager device 110 itself mayhave received the public key from the user device 111 via email, byscanning a QR code displayed on the user device 111 or any other way. Atthis point in time, device 111 is not yet authorized and therefore,simply referred to as “user device 111”. Once user device 111 isauthorized, it is referred to as “authorized device 111”. Accesscontroller 102 creates authorization data that indicates that userdevice 111 is an authorized device (as described below) and stores theauthorization data associated with the public key on the configurationmemory 115 to register the user device 111 as one of the multipleauthorized devices. This means keys and other data associated withauthorized device 111 are created and stored as described below. A usercan then use the authorized device 111 to unlock the DSD 100 simply bybringing the authorized device 111 into wireless communication range,such as within Bluetooth range. Again, the steps performed by authorizeddevice 111 are encoded in an app installed on authorized device 111.Depending on configuration parameters, the user may be required tounlock authorized device 111 before DSD 100 can be unlocked.

More particularly, access controller 102 has access to a non-volatileconfiguration data store, such as configuration memory 115, which may bea flash memory that is external to the access controller 102 (but mayequally be integrated into access controller 102). Configuration memory115 may also store the program code that implements the steps describedherein as being executed by access controller 102. It is noted that someexamples herein are configured under the assumption that an attacker canreadily unsolder and read out the content of the configuration memory115 but should not be able to decrypt the user content data with thatinformation. That is, in those examples, no keys are stored persistentlyin plain text on configuration memory 115 or elsewhere in DSD 100 onnon-volatile memory.

Once the cryptographic keys are available in plain text, they are storedonly in volatile memory (not shown). This means that a power-down of theDSD 100 erases all cryptographic keys stored in plain text. Additionalcircuitry may be provided to reset all remaining charges on power-down,power-up or external reset, so that it is physically impossible inpractice to recover any information from volatile memory. In many cases,power-down and erasure of all volatile memory occurs as a result of theuser disconnecting the USB cable from the host computer system 104. Inother examples, a secondary power supply is used which needs to bedisconnected to power down the DSD 100 to delete the volatile memory.

Challenge-Response

Configuration memory 115 has stored thereon data that is specific forthe registered authorized device 111. This data may be referred to as anidentifier of the authorized device 111 or as a public key associatedwith a corresponding private key stored on the authorized device 111.The public key may be a “transport public key” (TPK) and is generated bythe authorized device 111 on first launch of the app by executing anelliptic curve cryptography (ECC) primitive ECC-Pub({transport privatekey}). (Recall that while elliptic curve cryptography is used herein asexamples for reasons of computational efficiency and security, it isnoted that other cryptographic techniques could equally be used.) Thecorresponding private key is stored on authorized device 111. The accesscontroller 102 is configured to use the identifier (e.g., transportpublic key) or generate and store a further public key, to generate achallenge for the authorized device 111. It is noted here that thechallenge is unique in the sense that each challenge is different, sothat a subsequent challenge is different from any previous challenges.As described below, this is achieved by multiplying the stored data by arandom blinding factor. Then, the access controller 102 sends thechallenge to the authorized device 111 over a communication channel thatis different from the data path. For example, the data path may includea wire-based USB connection while the communication channel between theaccess controller 102 and the authorized device 111 is a wireless (e.g.,Bluetooth) connection.

In one example, a re-enrolment process takes place responsive to theauthorized device connecting with the DSD 100 for the first time afterthe authorization data was created and stored on configuration memory115 associated with the public key of the authorized device 111 receivedfrom the manager device 110. During the re-enrolment process, DSD 100updates the authorization data and as set out below may requestauthorized device 111 to generate an unlocking public key (and acorresponding unlocking private key) in addition to the transport publickey. The authorized device 111 then provides the unlocking public key tothe access controller 102.

This has the advantage that the two corresponding private keys(transport private key and unlocking private key) can be storedseparately on the authorized device and both keys can have differentaccess policies. For example, transport public key may be accessible atany time, even if the authorized device 111 is locked (e.g., by a screenlock or time out), so as to allow continuous communication betweenauthorized device 111 and DSD 100. To unlock DSD 100, however, theaccess policy of the unlocking private key may require that the userunlocks authorized device 111, enters a personal identification number(PIN), provides biometric or other authentication. This way, DSD 100cannot be unlocked by a stolen authorized device. Since unlocking DSD100 is performed only once while DSD 100 is powered, the increasedsecurity does not significantly reduce user convenience.

The authorized device 111 can calculate a response to the challenge thatcannot be calculated by any other device that is not registered with theDSD. More specifically, the correct response cannot be calculated by adevice that does not have access to data that corresponds to theidentifier stored on configuration memory 115. For example, authorizeddevice 111 uses the stored unlocking private key that is associated withthe corresponding unlocking public key stored on configuration memory115, to calculate the response to the challenge.

The access controller 102 receives the response to the challenge fromthe authorized device 111 over the communication channel. It is notedhere that if the access controller 102 simply validates the response tothe challenge and upon success, reads the cryptographic key fromconfiguration memory 115, the cryptographic key would be stored in plaintext, which is undesirable since this would enable an attacker todisassemble the DSD 100 and read the key from configuration memory 115to access the user content data stored on storage medium 105.

Calculate Key

So, instead, access controller 102 calculates the cryptographic keybased at least partly on the response from the authorized device 111.This means the cryptographic key is not a pure function of the responsebut involves other values as described in more detail below. In summary,the cryptographic key is stored in encrypted form on configurationmemory 115 and the response, which is based on the private key stored onthe authorized device, enables the calculation of the secret thatdecrypts the cryptographic key.

Throughout this disclosure, reference may be made to ‘wrapping’ of keys,which simply means that the key is encrypted by another key (i.e., bythe “secret”). In many cases of ‘wrapping’ the encryption is symmetricsuch that a single secret (key) exists that can decrypt the encryptedkey (without a public key associated with the secret). In one example,symmetric encryption uses the Advanced Encryption Standard (AES)primitive.

Finally, access controller 102 provides the cryptographic key to thecryptography engine 106 (via data port 103 in this example) to decryptthe encrypted user content data stored on the storage medium 105 of theDSD 100. As mentioned above, once the access controller 102 hascalculated the cryptographic key, the access controller 102 provides thecryptographic key to the data port 103 in plain text and the data port103 issues the SECURITY SET PASSWORD command to the cryptography engine106 including the cryptographic key.

It is noted that where reference is made to ‘unlocking’ the device, thiscan refer to the entire process described above including the challenge,the response to the challenge and sending of the cryptographic key tothe cryptography engine 106 to allow plain text read commands issued bythe host computer system. In other examples, the challenge and theresponse to the challenge are considered as being part of a separate‘connect’ step. During the following ‘unlocking’ step the accesscontroller 102 then sends the cryptographic key to the data port 103 toallow access to the user content data.

It is noted, as an aside, that it may be possible for an attacker toeavesdrop on the key transmission from the access controller 102 to thedata port 103 and then to the cryptography engine 106. However, thetransmission of the key is not over a public network, so thiseavesdropping would require gaining access to and disassembling theunlocked DSD without removing power from the DSD 100. This scenario maybe discarded as a threat since in this scenario the user content data isavailable anyway on host computer system 104. In other words, while theDSD 100 is connected and unlocked, data is available to the rightfuluser and the attacker. But once the user disconnects the DSD from hostcomputer system 104, this eavesdrop attack is not possible anymore.Therefore, this attack is not further considered.

For completeness it is noted that once the cryptography engine 106 hasreceived the cryptographic key, the host computer system 104 can issueordinary READ SEGMENT commands and transparently access the encrypteddata without any perceivable difference to accessing an unencrypteddevice. This is particularly the case where the cryptography engine hashardware cryptography modules to enable encryption and decryption at orabove the read and write speed of the storage medium 105 and/or the dataport 103. However, the user can disconnect the DSD 100 to lock it. Thisway, the DSD 100 can be carried by the user through insecure locationswhere the DSD 100 can be lost or stolen, but it is very difficult foranother person to decrypt the encrypted user content data stored onstorage medium 105. If the user maintains possession of the DSD, theuser can connect it to a second host computer system 116, convenientlyunlock the DSD 100 with his authorized device 111 (e.g., phone) andreadily access the encrypted user content data stored on the storagemedium 105.

For user convenience, the data port 103 can be configured such that ifthe DSD is locked, it registers with host computer system 104 as a massdata storage device with storage medium not present, similar to an SSDcard reader with no card inserted. Once the authorized device 111 isconnected to DSD 100 and the DSD 100 is unlocked, data port 103 switchesto storage medium present, similar to a card reader that had an SSD cardinserted. Such a configuration would avoid any warnings from beinggenerated by the operating system of the host computer system 104 aboutthe data not being accessible or access being denied. Instead, all userinteraction would be performed by the app installed on the authorizeddevice, which is fully controlled by the manufacturer of the DSD, souser experience can be optimized. As shown in FIG. 1, there may befurther mobile phones acting as authorized devices 117 and 118.

Beacons and Key Fobs

Considering FIG. 1 again, it can be seen that there are further devices,such as beacons 120 and key fob 121. These devices can also beconsidered as “authorized devices” since they can operate essentiallythe same as the authorized device 111. Before initial registration bythe manager device 110, these devices are referred to as “device to beauthorized”. When reference is made to a “user device” herein (mainlydescribing mobile phone 111 before initial registration), this alsoapplies to the beacons 120 and key fob 121 except when noted otherwise,such as in cases where user input is required. Beacons 120 and key fob121 also have their own private key stored securely so that they canrespond to a challenge that is specific for one beacon or key fob.However, since the beacons 120 and key fob 121 have no user input, theinitiation of communication may be slightly different. Moreparticularly, beacon 120 and key fob 121 may periodically sendadvertisements to broadcast their existence and the DSD 100 theninitiates the communication with beacon 120 and/or key fob 121, whichprompts them to send their transport public key. This is in contrast tothe authorized device 111, which sends the transport public key to theDSD 100 to initiate the communication.

In further examples, beacons 120 are in a de-activated state when theyare powered up and need to be activated by a manager device 110 or anauthorized device 111. This activation may follow a similar process asunlocking DSD 100. That is, manager device 110 or authorized device 111or both are registered with each beacon 120 with their transport publickeys and respond to a challenge as described herein. Thus, a device maybe registered as a manager device or an authorized device with one ofthe beacons 102 and/or key fob 121 without being registered with the DSD100 itself. If the response to the challenge is valid, beacons 120 thenunlock DSD 100. In yet a further example, beacons 120 are registeredwith each other, such that manager device 110 and/or authorized device111 need to activate only one of the beacons 120 and the remainingbeacons become activated automatically. In other words, the activation‘spreads’ through the beacon network as long as the beacons are in rangeof each other.

It is noted that the only piece of information that the authorizeddevices 111, 117, 118, 120 and 121 provide to the manager device 110 tobecome registered is one public key for each device. In other words,each device provides its own public key corresponding to a private keythat is securely stored on that device. Therefore, if an attackerintercepts the initial communication between one of the devices 111,117, 118, 120 and 121 and the manager device 110, the only informationthat the attacker can obtain is the public key. As the name suggests,the public key is not secret and can be generally known. Therefore, theattacker has not gained any advantage. Further, the manager device 110cannot use the public key to gain access to anything else related to theauthorized devices. For example, the manager device cannot decrypt orunlock any other data storage devices with which the authorized devicehas been registered by other manager devices.

The access controller 102 receives the public keys of the authorizeddevices from the manager device 110 and generates authorization data.Access controller 102 stores the authorization data on configurationmemory 115 waiting for the authorized device to connect for the firsttime. On the first connection, access controller 102 performs achallenge-response for the authorized device and upon success, updatesthe authorization data to indicate that the authorized device is nowfully registered. This first connection process is referred to as“re-enrolment” herein and details of generating the authorization dataand the re-enrolment are provided below.

Elliptic Curve Cryptography

In one example, the challenge generated by the DSD 100 and sent to theauthorized device 111 is based on elliptic curve cryptography. This hasthe advantages of shorter keys, which leads to more efficientcommunication and storage. Further, a large number of phones currentlyon the market provide dedicated functionality of elliptic curvecryptography within a secure hardware module. The secure hardware modulesecurely stores the user's private keys and performs cryptographicprimitives within the secure hardware module without the key leaving thesecure hardware module and being sent to a general purpose processorcore where the key may be subject to an attack for unauthorizedretrieval. In one embodiment, the secure hardware module includes aseparate processor that executes its own microkernel, which is notdirectly accessible by the operating system or any programs running onthe phone. The secure hardware module can also include non-volatilestorage, which is used to store 256-bit elliptic curve private keys. Inone embodiment, the secure hardware module is a Secure Enclavecoprocessor that is available on some Apple devices.

Authorized Device Data Record

FIG. 2 illustrates a section of configuration memory 115, according toan embodiment. More specifically, FIG. 2 illustrates one record 201, inconfiguration memory 115, which is associated with one of multipleauthorized devices and referred to herein as “authorization data”.Further data records for further authorized devices are schematicallyindicated as empty dashed boxes but not considered in detail as theyoperate in a similar manner to record 201. In particular, each furtherdata record comprises authorization data generated by the accesscontroller 102 in response to receiving a public key of a user devicefrom the manager device 110 and then updated during the first connectionof the user device (then “authorized device”). For convenience, the datastructure of configuration memory 115 is referred to as a ‘table’comprising one or more ‘records’, where each record relates to oneregistered authorized device and each record has multiple fields. It isnoted, however, that other data structures can be used, such asJavaScript Object Notation (JSON), Extensible Markup Language (XML),binary formats, etc. In one example, each entry has a fixed length andthe table has a fixed number of rows (i.e., entries). Within thisdisclosure, a ‘record’ may also be known as a ‘row’ or ‘entry’.

Record 201 comprises a field for a pre-authorization key 202, which isused responsive to the authorized device 111 connecting to the DSD 100for the first time. During this first connection, access controller 102performs a number of steps that are referred to as “re-enrolment” asdescribed below in more detail. The pre-authorization key 202 isgenerated from the identifier (e.g., the transport public key) of theauthorized device 111. For example, access controller 102 may generatethe pre-authorization key 202 by applying a key derivation functionusing the x-coordinate of the transport public key as an input parametertogether with an authorized device slot key as salt value to thederivation function. The authorized device slot key may be apseudo-random number (e.g., 16-bytes) stored on configuration memory 115and can be used to encrypt data in authorized device certificates sothat only the issuing DSD 100 can recover the information.

At that point, it can be said that the records stored on theconfiguration memory 115 are indexed by pre-authorization key 202 basedon an identifier of the authorized device (e.g., the transport publickey). As described below with reference to FIG. 4, the index of record201 may be stored in a certificate, as a slot number, duringre-enrolment and at that point the pre-authorization key 202 can bereplaced by a random value to make the configured DSD indistinguishablefrom a new device from the factory even with possession of the transportpublic key.

Record 201 further comprises a field for a first copy of a metadatawrapping key (MWK) 203 and a pre-authorization metadata wrapping key(PMWK) 214. Some fields in record 201 are encrypted which is indicatedby double-lined boxes, where the single solid line boxes, inside thedouble-lined boxes, indicate the ‘payload’ such as the metadata wrappingkey 203 and the pre-authorization metadata wrapping key 214. Thecorresponding encryption key, used to encrypt the payload, is noted atthe bottom of the double-lined box. So, for example, metadata wrappingkey 203 is encrypted by an authorized device metadata key (ADMK) 204. Itshould be noted that each encryption box may comprise an additionalnonce that is concatenated with the payload data. This guarantees thatthe encrypted entry cannot be distinguished from random data even withthe possession of the encrypted data, such as the transport public keyof the authorized device.

Record 201 further comprises a field for authorized device metadata(ADM) 205, which is a concatenation of a device type 206 (e.g., recoverykey, key fob, beacon, phone, computer, watch, etc.), a role of thedevice 207 (e.g., manager or user), a name of the device 208 (e.g.,“John's phone”), a transport public key 209, unlocking key metadata 210(e.g., key restrictions of whether fingerprint, pin or no unlock isrequired), an ephemeral public key 211, and an unlocking public key 212.In one embodiment, the ephemeral public key 211 is an elliptic curvepublic key generated from a random ephemeral private key (EPK) using anElliptic Curve Cryptography (ECC) primitive ECC-Pub(EUK). The ephemeralprivate key is not stored on configuration memory 115 or on theauthorized device 111 but is discarded after creating the ephemeralpublic key. This means that the ephemeral private key is not stored onnon-volatile memory but only on volatile memory. As result, a power-downof the memory leads to complete and irrecoverable loss (e.g.,destruction) of the ephemeral private key. The unlocking public key 212corresponds to an unlocking private key stored on authorized device 111and is generated by authorized device 111 and provided to the accesscontroller 102.

The authorized device metadata (concatenated with a further nonce) isencrypted by the metadata wrapping key (MWK) 213 that is also stored inencrypted form at 203. The main purpose of storing the encryptedmetadata wrapping key 203 in record 201 is to allow a manager user, whohas access to the authorized device metadata key 204, to access theencrypted authorized device metadata 205. If the metadata wrapping keywas not accessible to the manager, the manager would not be able toretrieve from the DSD 100 any information about which authorized devicesare currently registered. In one example, the authorized device metadatakey 204 is a single key for all authorized devices and is storedencrypted by a manager key. The manager key may be a pseudo-random value(e.g., 32 bytes) and generated by access controller 102 responsive tostorage medium 105 being erased. The manager key is encrypted and storedfor each paired manager device 110/114.

Record 201 further comprises a field for a second copy of device's role220 concatenated with a user key 221 and a second copy of the metadatawrapping key 222. It is noted that both role 207/220 and metadatawrapping key 203/222 are stored in two copies, which are identical butencrypted using different keys. The purpose of storing two copies of therole 207/220 is to enable the access controller 102 to verify the roleduring connection (responsive to the authorized device metadata beingdecrypted) as well as during unlocking (responsive to the user key 221being decrypted). The purpose of storing the first copy of the metadatawrapping key 203 is to provide it to a manager device having access tothe authorized device metadata key. The purpose of the second copy ofthe metadata wrapping key 222 is to provide it to a pre-authorizeddevice during the first connection. The concatenated values 220, 221,222 together are encrypted by an ephemeral unlock secret (EUS) 223 thatis originally generated by a Diffie-Hellman method using the ephemeralprivate key corresponding to ephemeral public key 211 and the unlockingpublic key 212. The ephemeral unlock secret 223 can be recovered usingthe ephemeral public key 211 and an associated unlocking private keystored on the authorized device 111 and corresponding to unlockingpublic key 212. In other words, the ephemeral unlock secret 223 can begenerated at the initial connection of the authorized device 111 to theDSD 100 using the ephemeral private key and the unlocking public key212. It is noted that the ephemeral private key itself is not stored butnevertheless, the ephemeral unlock secret 223 can be recovered asdescribed above. This means, the user key 221 is decryptable based onthe response from the authorized device. It is noted that the user key221 is identical for all authorized devices and can be used to decryptuser content data. This does not necessarily mean that the user keyitself decrypts the user content data. There may be further keys thatthe user key decrypts and the final key decrypts the user content data.The terms “using a key to decrypt user content data” and “enabledecryption of the user content data” refer to indirect encryption viamultiple keys in a chain. In contrast “the key decrypts the data” refersto direct decryption of the data with the key, such as modulomultiplication of the encrypted data by the key. Here, the user key 221is used to decrypt the data indirectly and may be the starting point ofa chain of keys that are decrypted sequentially until finally, the chainends at the key that decrypts the user content data. While in mostexamples disclosed herein, the ephemeral unlock secret 223 decrypts theuser key 221, it is also possible that the cryptographic key is derivedfrom the response to the challenge in other ways. For example, theresponse to the challenge may directly be used as the cryptographic keythat decrypts the user content data.

This allocation of keys and metadata enables a configuration where theentire configuration information about authorized devices, managerdevices, and other aspects is stored on the DSD 100 itself. However, theauthorized devices require a key stored on the respective authorizeddevice to unlock the DSD 100. If an unregistered user without access toany keys wants to access the entire configuration of the device, such asretrieve a list of registered devices, the unregistered user would needonly the recovery key to become registered as a manager device and gainaccess to the manager key. The DSD 100 can then provide the entirecontents of configuration memory 115 to the new manager device using themanager key. Further, there can be two manager devices and both canregister or remove authorized devices. The other manager device would beable to obtain configuration updates by synchronizing its own recordswith the data stored on configuration memory 115. In some examples, theDSD 100 is configured to erase records 201 of all authorized devices(but not delete the user content data or the user key 221, which may bestored as another copy in encrypted form on configuration memory 115separate from record 201 and other records) if the recovery key is usedto gain access but that is a policy decision.

FIG. 3 illustrates the control flow 300 between an authorized device 111and an access controller 102, according to an embodiment. First, theauthorized device 111 initiates a connect method by sending 301 itstransport public key. This step can be easily re-played by an attacker.Access controller 102 then replies 302 with a request for a certificateand in response to this request, authorized device 111 sends 303 acertificate previously obtained from the access controller 102 throughthe re-enrolment process.

Certificate

FIG. 4 illustrates a certificate 400 issued by the data storage device100 and sent by the authorized device 111 to the data storage device tounlock the data storage device, according to an embodiment. In thisexample, the certificate 400 comprises multiple type-length-value (TLV)fields, where the type value indicates the kind of field that is part ofthe certificate, length is the size of the value field (typically inbytes), and value is a variable-sized series of bytes which containsdata for this part of the certificate.

Certificate 400 begins with a TLV atom that indicates the type ofcertificate that follows. This is referred to as the certificate role401 and has a 2 byte value to indicate that this is an authorized devicecertificate.

Certificate 400 belongs to a certificate chain. Access controller 102uses the chain to validate and authenticate certificate 400. To indicatewhich chain certificate 400 belongs to, certificate 400 has a 4 byteroot certificate identifier (ID) 402. The certificate identifier of eachcertificate in the certificate chain is the same. Certificateidentifiers that do not match indicate an invalid certificate. In oneexample, a root certificate identifier indicates whether the certificatechain is a production or a development certification chain. In otherexamples, other groups may be indicated by respective certificateidentifiers.

Certificate 400 further comprises a 1 byte indicator of certificatedepth 403. A certificate's depth is defined as its distance from theroot certificate within its certificate chain. The root certificate isdefined to have a depth of zero. As a given certificate chain isprocessed the depth fields are validated to ensure integrity of thechain.

Certificate 400 also comprises a 64 byte certificate transport publickey 404 (e.g., according to the National Institute of Standards andTechnology (NIST) P-256 elliptic curve). Each certificate isdenoted/indexed via a transport public key. Each type of public key willhave its own dedicated tag type. That is, the tag type will denote thecipher suite used to generate the transport public key, such as theP-256 cipher suite.

Certificate 400 further comprises a data field 405 (explained below) andis authenticated via a signature 406. Access controller 102 receivescertificate 400 and validates the signature before trusting or using anyof the certificate's contents. To enable signature validation, the 64byte signer public key 407 is provided as part of the certificate. Thesignature 406 itself is 64 bytes in length and computed over all priorTLVs 401-405, 407 encountered within the certificate, regardless if theyare recognized by the implementation or not. More particularly, thesignature 406 is derived from a hash of the certificate data. Thespecific data that is signed is certificate dependent, but contains allTLVs used to represent the certificate, including TLVs that are notrecognized. The key used to generate the signature is a logical identitykey and is associated with signer public key 407.

Data field 405 comprises the slot number 410, which denotes the index ofthe record 201 within configuration memory 115. Data field 405 alsocomprises a further copy of the metadata wrapping key 411 (in additionto the two copies shown in FIG. 2). The data field 405 is encrypted withthe authorized device slot key (ADSK) 412, which is a 16 byte pseudorandom value stored in configuration memory 115 and is used to encryptdata in authorized device certificates so that only the issuing DSD 100can recover the information.

Unlocking the data storage device

Returning to FIG. 3, if the authorized device 111 wishes to unlock theDSD 100, the authorized device 111 sends 303 the certificate 400, whichincludes the encrypted metadata wrapping key (MWK) 213/411 to accesscontroller 102. The certificate 400 also includes the slot number 410,which is an index of the record 201 in configuration memory 115.

Access controller 102 uses the authorized device slot key stored inconfiguration memory 115 to decrypt 304 data field 405, and extract theslot number and metadata wrapping key. Access controller 102 thenqueries configuration memory 115 to read 305 the appropriate record 201from configuration memory 115 and decrypts 306 the authorized devicemetadata 205 using the metadata wrapping key. This yields the ephemeralpublic key 211, which may also be referred to as an identifier of theauthorized device because it uniquely identifies the authorized devicesince the ephemeral public key 211 is cryptographically associated withan unlocking private key stored only on authorized device 111. Accesscontroller 102 may perform additional checks 307, such as validate thatthe transport public key 209 included in the authorized device metadata205 matches the transport public key 404 presented in the certificate400. Further, access controller 102 validates the role 401 against thevalid set of values, and associates the role with the connection. Thismeans that access controller 102 is aware of the current role(authorized device or manager device) during the duration of connection.For example, access controller 102 stores a parameter value on volatilememory that indicates the role 401 provided in the certificate. If anyof the preceding checks fail, the authorized device is deemed to berevoked and an error to that effect is issued. Otherwise, the connectionattempt succeeds and the access controller 102 sends 308 a connectedconfirmation message to the authorized device 111.

At this stage, the authorized device 111 is connected and the unlockprocess begins 319 by the authorized device 111 sending 320 an unlockrequest to access controller 102. The unlock request includes theunlocking public key associated with the private unlocking key stored onthe authorized device's secure hardware module. Access controller 102matches 321 the received unlocking public key against the unlockingpublic key 212 stored in the authorized device metadata record 205.Next, access controller 102 generates 322 a new blinding value (alsoreferred to as unlock blinding key (UBK)), which essentially is anephemeral private scalar and is generated randomly.

Access controller 102 then generates the challenge based on theidentifier of the authorized device (e.g., ephemeral public key 211)multiplied by the unlock blinding key (UBK). More particularly, accesscontroller 102 multiplies 323 the ephemeral public key 211 by the unlockblinding key, returning the full X and Y coordinates of the result,noting that this operation is performed on an elliptic curve. Accesscontroller 102 then sends 324 the X and Y coordinates to the authorizeddevice 111 as the challenge. It is noted here that this challenge isbased on the identifier of the authorized device 111 because theephemeral public key is one factor of the multiplication resulting inthe challenge. It is further noted that for each unlock request (i.e.,320) a different unlock blinding key is generated to avoidman-in-the-middle attacks.

Further, access controller 102 computes 325 the inverse of the unlockblinding key (UBK⁻¹). The access controller 102 can compute the inverseof the unlock blinding key while waiting for a response from theauthorized device 111.

The authorized device 111 calculates a response to the challenge bymultiplying 326 the challenge with the unlocking private key, which isstored in the authorized device's secure hardware module and whichcorresponds to unlocking public key 212 stored on configuration memory115. This may involve the execution of a cryptographic primitive thatcan be executed entirely within the secure hardware module within theauthorized device 111. Authorized device 111 then sends back 327 theresult in a response message. Access controller 102 multiplies 328 thereturned result with the inverse of the unlock blinding key to computethe ephemeral unlock secret (EUS) 223.

In mathematical notation, P represents the ephemeral public key, and krepresents the unlock blinding key created at step 322 in FIG. 3. Accesscontroller 102 calculates 323 the product k*P and sends 324 it to theauthorized device 111. The authorized device 111 multiplies 326 thechallenge with the unlocking private key j to calculate j*k*P andreturns 327 the result to access controller 102. The access controller102 multiplies 238 this response with the inverse of the unlock blindingkey k⁻¹ to calculate

k⁻¹*j*k*P

which is equal to j*P due to commutative nature of elliptic curves

(i.e., k ⁻¹ *j*k*P=k*k ⁻¹ *j*P=j*P).

Access controller 102 then uses j*P as the ephemeral unlock secret(i.e., key) to decrypt 329 user key 221. That is, access controller 102uses the ephemeral unlock secret to decrypt the user key 221, stored onthe DSD 100, which is encrypted with the ephemeral unlock secret. Moreparticularly, access controller 102 decrypts 329 the user key, whichthen decrypts 330 a “user drive key”, which is then, finally, sent 331to cryptography engine 106 via TCG commands. That is, the user drive keymay be generated by access controller 102 using a key derivationfunction based on the user key. The user drive key is the TCG credentialused to unlock the DSD 100 and may be equated to the “cryptographic key”described herein. In the case of Opal, this is the User2 credential.

It is noted that the ephemeral unlock secret is generated during there-enrolment process by deriving a symmetric key from the result of anElliptic Curve Diffie-Hellman process using the unlocking private keystored on the authorized device 111 and the unlocking public key 212.The resulting key is used to encrypt the user key 221 but not stored inDSD 100. Instead, it is re-generated each time an authorized devicerequests to unlock the DSD 100, as described above.

In a further example, the unlocking private key j, in the equationsabove, can be replaced by a product of the unlocking private key with avalue derived from a passphrase. The unlocking private key would stillbe stored in the secure hardware module of the authorized device but theunlocking private key alone would not be able to decrypt the usercontent data stored on the DSD 100. Instead, the user needs to enter thepassphrase to calculate the response to the challenge and send 327 thatresponse. This would simply replace j above with the product of j withthe passphrase value. The DSD would be oblivious of that change becausethe ephemeral unlock secret 223 would be generated in the same way asabove from the view of the access controller 102.

Registration and Re-Enrollment

It is noted that the data record 201 shown in FIG. 2 is shown after theauthorized device 111 has completed the re-enrolment process and isallowed to decrypt the encrypted user content data. Again, there arethree steps overall: First, the manager device 110 registers a userdevice 111 once as one of multiple authorized devices. Second, theauthorized device 111, on first connection with the access controller102, re-enrolls once to complete the generation of the involved keys.Third, the authorized device 111 subsequently connects with the accesscontroller 102 to unlock the DSD 100. This third step can occur multipletimes.

During the (initial) registration step initiated by the manager device110, access controller 102 receives from the manager device 110 a publickey corresponding to a private key stored on the user device 111. Inresponse, access controller 102 creates authorization data, which issimilar to the data record 201 in FIG. 2 with the exception that theunlocking public key 212 field holds the transport public key 209 (asreceived from the manager device 110) because the unlocking public keyhas not yet been generated. Access controller 102 generates thepre-authorization key 202 that is essentially an index to locate therecord 201. The pre-authorization key is generated by a key generationfunction using the x coordinate of the received transport public key 209and a salt value. The salt value may be an authorized device slot key,which may be a 16-bytes pseudo-random value generated during the “takeownership” process, stored on the configuration memory 115, and notshared with the authorized device. This way the salt can be differentafter each “factory reset”, such as each time a manager device takesownership of the DSD 100.

Creating the authorization data stored in record 201 further comprisesgenerating the metadata wrapping key 222, such as by generating a16-bytes pseudo-random value. Access controller 102 stores the metadatawrapping key in field 222. Further, access controller 102 generates theephemeral unlock secret 223 and encrypts the role 220 (e.g., “authorizeddevice”), user key 221 and the new metadata wrapping key 222 with theephemeral unlock secret 223. Then access controller 102 generates anephemeral public key 211 from the ephemeral unlock secret 223 anddiscards ephemeral unlock secret 223.

Recall that during the (initial) registration step initiated by themanager device 110, access controller 102 creates authorization data,which is similar to the data record 201 in FIG. 2. In contrast to FIG.2, the authorized device metadata 205 is not encrypted by the newmetadata wrapping key but by a pre-authorization metadata wrapping keybecause the actual metadata wrapping key 222 is not yet available to theauthorized device 111. The pre-authorization metadata wrapping key maybe identical to the pre-authorization key 202 at this stage or generatedseparately. It is noted that the pre-authorization metadata wrappingkey, which now encrypts the authorized device metadata 205 can begenerated only by the access controller 102 and not provided by theauthorized device 111 because the authorized device 111 does not haveaccess to the authorized device slot key that is used to generate thepre-authorization metadata wrapping key.

So, responsive to the authorized device 111 first connecting with theaccess controller 102, authorized device 111 sends its transport publickey to access controller 102. Access controller 102 uses the transportpublic key and the stored authorized device slot key to generate thepre-authorization key 202. Access controller 102 can then search for thepre-authorization key 202 in the configuration memory 115 to retrieverecord 201. Access controller 102 can also use the pre-authorization keyas the pre-authorization metadata wrapping key to decrypt the authorizeddevice metadata 205.

As described above, access controller 102 generates a challenge usingthe ephemeral public key 211 and an unlock blinding key. Accesscontroller 102 then creates the ephemeral unlock secret 223 from theresponse. It is noted that only the authorized device 111 with theprivate key corresponding to transport public key 209 can create a validresponse. This means that even if an attacker disassembles theconfiguration memory 115 and reads the authorized device slot key togenerate the pre-authorization metadata wrapping key to decrypt theephemeral public key 211, the attacker would still not be able togenerate the ephemeral unlock secret 223.

Access controller 102 validates the response by checking that theresponse works as ephemeral unlock secret 223 and in response, updatesthe authorization data in record 201. More particularly, accesscontroller 102 checks whether field 212 for the unlocking public key isidentical to the transport public key 209. In response to both beingidentical (as set out above), access controller 102 requests a newunlocking public key from authorized device 111 and stores the returnedkey as unlocking public key 212.

Access controller further decrypts the metadata wrapping key 222 thatwas generated during registration by the manager device 110. At thisstage, access controller 102 may re-generate the ephemeral unlock secret223, encrypt role 220, user key 221, and metadata wrapping key 222,re-generate and store the ephemeral public key 211 and discard theephemeral unlock secret 223. Finally, access controller encrypts theauthorized device metadata 205 with the metadata wrapping key 222 andoverwrites the pre-authorization key 202 with random values to make theconfiguration memory 115 indistinguishable from random data even withthe possession of the transport public key and/or the unlocking publickey. This concludes the update of the authorization data stored inrecord 201 and the registration process. As a result, the authorizeddevice 111, as one of multiple authorized devices, is now allowed todecrypt the encrypted user content data through the unlocking steps setout above.

The process described above, involving the creating and update ofauthorization data, enables the registration of multiple authorizeddevices using only their public keys during the first step ofregistration by the manager device 110. This way, no secret informationneeds to be shared that could potentially be intercepted and used formalicious unlocking of other devices of the user.

Recovery Key

Upon taking ownership of the DSD 100, the access controller 102generates a recovery key and provides the recovery key to the managerdevice 110. The recovery key can then be stored on a secure storage 113or printed on paper and locked away. Ultimately, the recovery key can beused by a recovery manager device 114 to assume the manager role thatthe manager device 110 previously had.

More particularly, the recovery key is associated with a recovery keyrecord 250 stored in configuration memory 115, which is also referred toas authorization data. In this example, the recovery key record 250 hasan identical data structure compared to authorized device record 201,which means the same fields appear in both records 201/250. In oneexample, the first record in configuration memory 115 is assigned to therecovery key. In this recovery key record 250, the pre-authorization key252 is a random value, because it is known that the recovery key record250 is the first record, so no index is required. Further, theauthorized device metadata 255 is encrypted using the pre-authorizationmetadata wrapping key 263. Note that, as described above, accesscontroller 102 generates the pre-authorization metadata wrapping key 263based on the transport public key 259 (which is the recovery public keyin this case) and the authorized device slot key (not shown) that isstored on configuration memory 115 separately from the records 201/250(by executing a key generation function with inputs being thex-coordinate of the transport public key as the key material and theauthorized device slot key as the salt). The difference betweenpre-authorization metadata wrapping key 263 and pre-authorizationmetadata wrapping key 214 is that they are generated using theircorresponding public transport keys 259 and 209, respectively. Thepre-authorization metadata wrapping key 264 is also stored in record 250and encrypted by the authorized device metadata key 254 together withthe metadata wrapping key 253 that may be identical to thepre-authorization metadata wrapping key. A second copy of the metadatawrapping key 272 is stored encrypted by an ephemeral unlock secret 273together with the manager key 271 and role (unused for the recovery keyentry) 270. It is noted that the copies of the metadata wrapping key 253and 272 and the pre-authorization metadata wrapping key 264 are notrequired for the processes disclosed herein and can be replaced byrandom data. They are not random data in this example so that the valuesare consistent with authorized device record 201.

The authorized device metadata 255 comprises a device type 256 (e.g.,“recovery key”), a role (unused) 257, a name (unused) 258, and arecovery public key 259, which is the public key corresponding to therecovery private key sent to the manager device 110. It is noted thatthe field that holds the recovery public key holds the transport publickey in entries for authorized devices and manager devices. Theauthorized device metadata 255 further comprises unlocking key metadata(unused) 260 and the public key ECC-Pub(EUK) 261 corresponding to thepublic key that was used to generate the ephemeral unlock secret 273.Finally, authorized device metadata 255 comprises an unlocking publickey 262 which is identical to the transport public key (i.e., therecovery public key).

As mentioned above, the recovery key is a private key that has acorresponding public key that can be calculated from the private key.However, it is desirable that the recovery private key (RPK) is nottransmitted in plain text at recovery as there is no securecommunication channel. So, a user obtains the recovery private key (suchas printed on paper) and enters the recovery private key into therecovery manager device 114 (that is not yet registered or known to theDSD 100). The recovery manager device 114 calculates the recovery publickey from the private recovery key (such as ECC-Pub(RPK)) and sends therecovery public key to the access controller 102, similar to how managerdevice 110 and authorized device 111 (including beacons 120 and key fob121) send their respective transport public keys to access controller102 to unlock the DSD 100.

In contrast to the process involving manager device 110 and authorizeddevice 111 (including beacons 120 and key fob 121), the recovery managerdevice 114 has no stored certificate as it has only the public andprivate recovery keys available. Therefore, recovery manager device 114cannot provide the index of its corresponding record 201 inconfiguration memory 115. Therefore, it is useful that the recovery keyrecord 250 is the first entry in the configuration memory 115. Thismeans, access controller 102 receives the recovery public key, generatesa corresponding pre-authorization metadata wrapping key 263 and attemptsto decrypt the authorized device metadata 255. If that attempt issuccessful, access controller 102 obtains the device type 256, whichshould be “recovery key”, and the recovery public key 259 which can bechecked against the recovery public key provided by the recovery managerdevice 114. The role field 257 may be “manager device” as the managerkey field 271 holds the manager key. The unlocking public key 262 may beidentical to the recovery public key 259.

Once the authorized device metadata 255 is decrypted, the accesscontroller 102 sends a challenge to the recovery manager device 114 asdescribed above. That is, access controller 102 generates a blindingvalue and uses that together with the ECC-Pub(EUK) 261 to calculate thechallenge. The response enables access controller 102 to calculate theephemeral unlock secret 273, which decrypts the manager key 271. Withthe manager key 271 available, access controller 102 can now read andchange all configuration data stored on configuration memory 115 and asa result, recovery manager device 114 has gained full manager access. Inone example, the user key 221 is derived directly from the manager key271 by way of a key derivation function without further secret inputs,which means that while the manager key 271 is available, it is alwayspossible to calculate the user key. Since the user key 221 decrypts theuser drive key (not shown) as described above, it can be said thataccess controller 102 enables, based on the response from the recoverymanager device 114, decryption of the encrypted user content data.

In one example, access controller 102 deletes all records 201 ofauthorized devices when the recovery public key is provided. Thisprevents users from distributing the recovery key as a convenient meansfor granting access to colleagues, etc. In a further example, accesscontroller 102 creates a new record, similar to record 201, for therecovery manager device 114 upon decrypting the manager key 271. Thatis, access controller 102 requests a new transport public key 209 and anew unlocking public key 212 and encrypts the manager key in field 221by a new ephemeral unlock secret 223. Access controller 102 may alsogenerate a new recovery private key. It is noted that the recoverypublic key is not ‘public’ in the sense that it is broadcast or known bythe public. The recovery public key is calculated by the recoverymanager device 114 and sent once to the access controller 102. Therecovery public key is named ‘public’ because it is calculated using apublic key generation function ECC-Pub. However, even if the recoverypublic key was published and known to an attacker, the attacker couldderive the pre-authorization metadata wrapping key and decrypt theauthorized device metadata 205 and therefore distinguish theconfiguration memory 115 from random data. However, all that theattacker would see is that there is an entry for a recovery key. Thatentry exists for every DSD 100 that has been taken ownership of in thepast (and could even be generated at the factory and overwritten on“take ownership”). It does not show the attacker that any authorizeddevices have been registered.

After assuming the new manager role (by way of creating a manager devicerecord 201), recovery manager device 114 can create further entries forone or more authorized devices based on their public keys as describedabove. It is further noted that it is possible to re-generate a newmanager key in response to receiving the recovery public key anddecrypting the manager key 271, which would automatically render allauthorized device entries unusable since they store the previous userkey, which is now different from the user key derived from the newmanager key. In response to generating a new manager key, accesscontroller 102 decrypts the user drive key (not shown) with the previoususer key, stores the user drive key temporarily on volatile memory andencrypts the user drive key with the new user key. Access controller 102would also re-write authorized device entries that are to be maintainedwith the new user key.

It is noted that some operations above render authorized device entriesunusable while the previous (now invalid) user key can still bedecrypted. This may result in an attempt to decrypt the user contentdata with an incorrect cryptographic key, which may result in invaliddata (garbled/random) being returned to the host computer system 104. Toprevent this, an entry randomized bitmap may provide one bit per entrywhich indicates whether that entry is valid.

Method for Unlocking Using a Recovery Key

FIG. 5 illustrates a method 500 for unlocking a data storage device 100,according to an embodiment. The method commences by access controller102 generating 501 a recovery private key, such as by generating arandom value or a 32 byte randomly generated elliptic curve cryptography(ECC) private scalar. In examples disclosed herein, the recovery privatekey is not stored on non-volatile memory in the data storage device.Access controller 102 also generates 502 encrypted authorization data250 based on the recovery private key and stores 502 the encryptedauthorization data on a data store. In the example of FIG. 2, accesscontroller 102 calculates the recovery public key from the recoveryprivate key, and the authorization data 250 comprises the recoverypublic key 259 corresponding to the recovery private key, encrypted bythe pre-authorization metadata wrapping key 263 that is derived from therecovery public key. Therefore, the authorization data 250 is said to be“based on” the recovery private key. Access controller 102 then sends503 data indicative of the recovery private key to manager device 110registered with the DSD 100. The data indicative of the recovery keyshould then be stored safely by a manager user, such as printed on paperand locked in a safe. The data indicative of the recovery key may be therecovery key itself in plain text or other data that allows unambiguousderivation of the recovery private key, such as a mnemonic code orsentence also referred to as seed phrase.

The manager device 110 is registered by way of an entry as shown in FIG.2 and described above that comprises the encrypted manager key insteadof user key 221, noting that the user key can be directly derived fromthe manager key. The three preceding steps 501, 502, and 503 areperformed during or soon after the “take ownership” process, such asafter the manager device 110 has been registered. The following stepsare then performed when the manager device 110 has been lost or stolenand it is necessary to recover access to the DSD 100 by use of therecovery key.

When a user wishes to recover access, the user installs the app, asmentioned earlier, onto their recovery manager device 114 (which is notyet registered as such), such as a phone, and enters the recoveryprivate key from the paper printout. The app may store the recoveryprivate key in the recovery manager device's 114 secure hardware moduleand calculates the recovery public key corresponding to the enteredrecovery private key. The app then connects to the DSD 100 and sends thecalculated recovery public key to the access controller 102. Asdisclosed herein, this connection may be wireless, such as usingBluetooth. Consequently, access controller 102 receives 504 the recoverypublic key, calculated based on the recovery private key, from therecovery manager device 114 over a communication channel that isdifferent from the data path 101. Access controller 102 can then decrypt505 the encrypted authorization data based on the recovery public key byderiving the pre-authorization metadata wrapping key using theauthorized device slot key stored on the configuration memory 115. Thisdecryption provides the public key ECC-Pub(RPK) which enables accesscontroller 102 to generate 506 a challenge for the recovery managerdevice 114 based on the decrypted authorization data as described abovewith respect to the authorized device 111. Accordingly, accesscontroller sends 507 the challenge to the recovery manager device 114over the communication channel that is different from the data path 101.Recovery manager device 114 calculates a response based on the storedrecovery private key (as entered by the user) and corresponding to theunlocking private key described above. Subsequently, access controllerreceives 508 a response to the challenge from the recovery managerdevice 114 over the communication channel. Finally, the accesscontroller enables 509, based at least partly on the response,decryption of the encrypted user content data. That is, accesscontroller 102 uses the response to calculate the ephemeral unlocksecret 273, which decrypts the manager key 271, which enables directderivation of the user key 221, which decrypts the user drive key (notshown), which decrypts the user content data (potentially with furtherkeys in a chain).

Registering the Data Storage Device

The data port 103 registers, with the host computer system 104, as ablock data storage device. For example, Universal Serial Bus (USB)devices provide information in the form of a USB device descriptor. TheUSB device descriptor contains relevant information about the device.Accordingly, in embodiments in which the data storage device isconnected to a host computer system via a USB connection, the datastorage device registers with the host computer system as a block datastorage device by configuring its USB device descriptor to indicate thatthe data storage device is a block data storage device.

The USB device descriptor provides structured information regarding theUSB device such as the class of device, protocols supported, type ofdevice, manufacturer and other configuration parameters. An operatingsystem of a host computer can obtain the USB device descriptor of thedata storage device by sending various standard control requests (e.g.,GET DESCRIPTOR requests) to the data storage device. In response toreceiving these requests, the data storage device provides the USBDEVICE DESCRIPTOR to the host computer system, thus registering the datastorage device with the host computer system as a block data storagedevice .The host computer interprets the USB DEVICE DESCRIPTOR todetermine the configuration and capabilities of the data storage device.The host computer system may then store information regarding the datastorage device in the registers of the operating system of the hostcomputer system.

It will be appreciated by persons skilled in the art that numerousvariations and/or modifications may be made to the above-describedembodiments, without departing from the broad general scope of thepresent disclosure. The present embodiments are, therefore, to beconsidered in all respects as illustrative and not restrictive.

1. A data storage device comprising a data path and an accesscontroller, wherein: the data path comprises: a data port configured totransmit data between a host computer system and the data storagedevice; a non-volatile storage medium configured to store encrypted usercontent data; and a cryptography engine connected between the data portand the storage medium and configured to use a cryptographic key todecrypt the encrypted user content data stored on the storage medium inresponse to a request from the host computer system; and the accesscontroller is configured to: generate a recovery private key; generateencrypted authorization data based on the recovery private key; storethe encrypted authorization data in a data store; send data indicativeof the recovery private key to a manager device; receive a recoverypublic key, calculated based on the recovery private key, from arecovery manager device over a communication channel that is differentfrom the data path; decrypt the encrypted authorization data based onthe recovery public key; generate a challenge for the recovery managerdevice based on the decrypted authorization data; send the challenge tothe recovery manager device over the communication channel that isdifferent from the data path; receive a response to the challenge fromthe recovery manager device over the communication channel; and based atleast partly on the response, enable decryption of the encrypted usercontent data.
 2. The data storage device of claim 1, wherein therecovery private key is stored on the recovery manager device and theresponse is based on the recovery private key stored on the recoverymanager device.
 3. The data storage device of claim 2, wherein themanager key enables configuration of the access controller to enabledecryption of the encrypted user content data.
 4. The data storagedevice of claim 3, wherein the manager key enables registration of anauthorized device with the access controller to enable decryption of theencrypted user content data in response to the authorized device beingconnected to the data storage device.
 5. The data storage device ofclaim 4, wherein: registration of the authorized device comprisescreation of an entry as further encrypted authorization data in the adata store based on a public key associated with the authorized device;the entry comprises an encrypted user key calculated based on themanager key; and the access controller is configured to determine thecryptographic key based on the user key.
 6. The data storage device ofclaim 5, wherein: the encrypted authorization data based on the recoveryprivate key has a first structure that is identical to a secondstructure of encrypted authorization data based on the public keyassociated with the authorized device that is authorized to unlock thedata storage device by responding to a challenge generated by the accesscontroller.
 7. The data storage device of claim 6, wherein the firststructure and the second structure comprise a respective public keyfield, the access controller is configured to store the recovery publickey in the public key field of the first structure and to store thepublic key associated with the authorized device in the public key fieldof the second structure.
 8. The data storage device of claim 5, whereinthe user key is directly derivable from the manager key.
 9. The datastorage device of claim 1, wherein the access controller is furtherconfigured to determine, based at least partly on the response, amanager key to enable decryption of the encrypted user content data. 10.The data storage device of claim 8, wherein the access controller isfurther configured to determine the cryptographic key based on themanager key.
 11. The data storage device of claim 1, wherein theencrypted authorization data comprises metadata encrypted by apre-authorization metadata wrapping key that is derivable from therecovery public key.
 12. The data storage device of claim 11, whereinthe access controller is configured to derive the pre-authorizationmetadata wrapping key by performing a key derivation function using therecovery public key as an input.
 13. The data storage device of claim12, wherein the access controller is further configured to perform thekey derivation function using an authorized device slot key as a furtherinput.
 14. The data storage device of claim 13, wherein the authorizeddevice slot key is stored on the data store in plain text.
 15. The datastorage device of claim 11, wherein: the access controller is configuredto generate the challenge for the recovery manager device based on themetadata; and the encrypted authorization data comprises a manager keythat is encrypted by an unlock secret that is derivable from theresponse to enable decryption of the encrypted user content data. 16.The data storage device of claim 15, wherein: the metadata comprises anelliptic curve public key corresponding to an ephemeral unlock key; andthe unlock secret is based on the ephemeral unlock key.
 17. The datastorage device of claim 1, wherein the access controller is configuredto delete authorization data other than the generated encryptedauthorization data based on the recovery private key in response toenabling decryption.
 18. The data storage device of claim 1, wherein therecovery public is calculated by the access controller and the recoverymanager device.
 19. A method for unlocking a data storage device thatstores encrypted user content data, the method comprising: generating arecovery private key; generating encrypted authorization data based onthe recovery private key; storing the encrypted authorization data in adata store; sending data indicative of the recovery private key to amanager device; receiving a recovery public key, calculated based on therecovery private key, from a recovery manager device over acommunication channel; decrypting the encrypted authorization data basedon the recovery public key; generating a challenge for the recoverymanager device based on the decrypted authorization data; sending thechallenge to the recovery manager device over the communication channel;receiving a response to the challenge from the recovery manager deviceover the communication channel; and enabling, based at least partly onthe response, decryption of the encrypted user content data.
 20. A datastorage device comprising: means for generating a recovery private key;means for generating encrypted authorization data based on the recoveryprivate key; means for storing the encrypted authorization data in adata store; means for sending data indicative of the recovery privatekey to a manager device; means for receiving a recovery public key,calculated based on the recovery private key, from a recovery managerdevice over a communication channel; means for decrypting the encryptedauthorization data based on the recovery public key; means forgenerating a challenge for the recovery manager device based on thedecrypted authorization data; means for sending the challenge to therecovery manager device over the communication channel; means forreceiving a response to the challenge from the recovery manager deviceover the communication channel; and means for enabling, based at leastpartly on the response, decryption of the encrypted user content data.